System for connecting a driver and a rider

ABSTRACT

A system for connecting a driver and a rider comprises a processor and an interface. The processor is configured to select a driver for a requested ride from the rider. The interface is configured to, in the event that the driver accepts the rider, provide a connect notification to the rider. The connect notification comprises an image associated with the driver, an image associated with the driver&#39;s car, and an anonymized interface for contacting the driver.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.16/673,120, filed on Nov. 4, 2019, which is a continuation of U.S.application Ser. No. 13/828,913, filed on Mar. 14, 2013, now U.S. Pat.No. 10,467,554, issued on Oct. 16, 2019. The aforementioned applicationsare hereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

Mobile device technology enables people to communicate from anylocation. However, people still need to move between locations. Eventhough there are many people driving and there are many people who wishto go to a different location from where they are, the people who wishto go are not typically driven by the many people driving.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 is a block diagram illustrating an embodiment of a system forconnecting a driver and a rider.

FIG. 2 is a block diagram illustrating an embodiment of a liftmanagement system.

FIG. 3 is a block diagram illustrating an embodiment of a user system.

FIG. 4 is a diagram illustrating an embodiment of a user device displayfor a default display for indicating a pickup address to a rider system.

FIG. 5 is a diagram illustrating an embodiment of a user device displayfor indicating a dropoff address to a rider system.

FIG. 6 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider system to request a ride.

FIG. 7 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that drivers are being contacted.

FIG. 8 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that a driver has accepted a ride request.

FIG. 9 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that the ride is complete.

FIG. 10 is a diagram illustrating an embodiment of a user device displayfor menu options.

FIG. 11 is a diagram illustrating an embodiment of a user device displayfor a default display for a driver system.

FIG. 12 is a diagram illustrating an embodiment of a user device displayfor receiving a ride request for a driver system.

FIG. 13 is a diagram illustrating an embodiment of a user device displayfor a driver system while driving to pick up a passenger.

FIG. 14 is a diagram illustrating an embodiment of a user device displayfor rating a passenger for a driver system.

FIG. 15 is a flow diagram illustrating an embodiment of a process forgetting a ride.

FIG. 16 is a flow diagram illustrating an embodiment of a process forgiving a ride.

FIG. 17 is a flow diagram illustrating an embodiment of a process forindicating a lead location.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

A system for connecting a driver and a rider comprises an interface forproviding a display information with potential drivers to the rider;and, in the event that a selected driver accepts the rider, providing aconnect notification to the rider; wherein the connect notificationcomprises: an image associated with the driver, an image associated withthe driver's car, and an anonymized interface for contacting the driver.The system for connecting a driver and a rider additionally comprises aprocessor configured to determine whether the selected driver acceptsthe rider. In some embodiments, the system for connecting a driver and arider additionally comprises a memory coupled to the processor andconfigured to provide the processor with instructions.

A system for connecting a driver and a rider is disclosed. A system forconnecting a driver and a rider comprises an app running on a mobiledevice used by a prospective driver and a prospective rider. In someembodiments, the app comprises a driver mode and a rider mode and can betoggled between the two modes. When a rider starts the app he receives adisplay of drivers that may be able to give him a ride. The rider canissue a ride request if desired. When the rider issues a ride request,the system provides a notification to a selected driver. In someembodiments, the selected driver has a time limit to respond to thenotification. If the driver elects to deny the notification, thenotification is provided to a next selected driver. If the driver electsto accept the notification, the driver and the rider are connected. Aconnection notification is provided to the driver. In some embodiments,the driver receives information regarding the rider (e.g., an image, aspecific location for pickup, an anonymized contact number, etc.). Aconnect notification is provided to the rider. The connect notificationcomprises images associated with the driver and the driver's car, and ananonymized interface for contacting the driver. In some embodiments, theanonymized interface comprises a button the rider can use to contact thedriver via the system for connecting a driver and a rider withoutrevealing any of the driver's personal information to the rider. Thedriver drives to the location of the rider, picks him/her up, and driveshim/her to his/her destination. When the ride is complete, the rider ispresented with an interface including a suggested donation for thedriver and a driver rating screen. At the end of each day, the driver ispresented with a donation summary indicating the total donationsreceived over the course of the day's driving.

FIG. 1 is a block diagram illustrating an embodiment of a system forconnecting a driver and a rider. In the example shown, FIG. 1 comprisesnetwork 100. In various embodiments, network 100 comprises one or moreof the following: a local area network, a wide area network, a wirednetwork, a wireless network, the Internet, an intranet, a storage areanetwork, a cellular network, or any other appropriate communicationnetwork. Rider system 102 and driver system 104 comprise user systems(e.g., computing systems for operation by users). In some embodiments,one or more of rider system 102 and driver system 104 comprises a systemaccessed by a user directly (e.g., the user is in proximity with theuser system). In some embodiments, one or more of user system 102 anduser system 104 comprises a system accessed by a user remotely (e.g.,the user is not in proximity with the user system, and accesses the usersystem via network 100 and a separate user system). In the exampleshown, rider system 102 and driver system 104 comprise mobile devices(e.g., smartphones, tablet computers, etc.). Rider system 102 and driversystem 104 comprise systems accessing lift management system 106 (e.g.,accessing lift management system 106 via network 100). In variousembodiments, there are 2, 5, 22, 122, 4320, 26100, or any otherappropriate number of user systems (e.g., rider systems and driversystems) accessing lift management system 106. Lift management system106 comprises a system for managing drivers giving riders lifts. In someembodiments, lift management system 106 comprises a system forconnecting a rider and a driver. In some embodiments, lift managementsystem 106 comprises a system for managing rider donations. In someembodiments, lift management system 106 comprises a system fordispatching drivers. In various embodiments, lift management system 106comprises a computer, a computer with multiple processors, multiplecomputers connected via a local network, multiple computers connectedvia a wide area network, multiple computers connected via the Internet,multiple computers connected via network 100, or any other appropriatecomputing system or systems. In various embodiments, the processorscomprising rider system 102, driver system 104, and lift managementsystem 106 comprise any one of a variety of proprietary or commerciallyavailable single or multi-processor systems (e.g., an Intel™-basedprocessor) or other type of commercially available processor able tosupport communications in accordance with each particular embodiment andapplication.

FIG. 2 is a block diagram illustrating an embodiment of a liftmanagement system. In some embodiments, lift management system 200comprises lift management system 106 of FIG. 1 . In the example shown,lift management system 200 comprises interface 202. In variousembodiments, interface 202 comprises an interface for receiving riderequests, sending rider notifications, receiving rider accept and denyindications, sending connect notifications, receiving locationinformation, sending and receiving ride start notifications, sending andreceiving ride complete notifications, sending and receiving donationinformation, sending and receiving driver rating information, sendingand receiving rider rating information, sending donation summaryinformation, or sending or receiving any other appropriate information.In some embodiments, interface 202 communicates with a user system(e.g., a driver mobile device or a rider mobile device) via a network.Processor 204 comprises a processor for receiving and processing andproviding information. In some embodiments, processor 204 communicateswith interface 202. Processor 204 receives information from interface202 and determines what information should be sent by interface 202. Insome embodiments, processor 204 determines whether a driver is offered arequest from a rider. Memory 206 comprises a memory coupled to processor204 and configured to provide processor 204 with instructions. Driverdatabase 208 comprises driver information (e.g., driver names, driverschedules, driver histories, driver ratings, driver donation amounts,driver images, driver car images, etc.) Rider database comprises riderinformation (e.g., rider names, rider histories, rider ratings, riderdonation amounts, rider images, etc.). Map database 212 comprises mapinformation. In some embodiments, processor 204 uses map informationfrom map database 212 to plan routes.

FIG. 3 is a block diagram illustrating an embodiment of a user system.In some embodiments, user system 300 of FIG. 3 comprises rider system102 of FIG. 1 . In some embodiments, user system 300 of FIG. 3 comprisesdriver system 104 of FIG. 1 . In the example shown, user system 300comprises interface 302. In various embodiments, interface 302 comprisesan interface for sending ride requests, receiving rider notifications,sending rider accept and deny indications, receiving connectnotifications, sending location information, sending and receiving ridestart notifications, sending and receiving ride complete notifications,sending and receiving donation information, sending and receiving driverrating information, sending and receiving rider rating information,receiving donation summary information, or sending or receiving anyother appropriate information. Processor 304 receives information frominterface 302 and determines what information should be sent byinterface 302. Memory 306 comprises a memory coupled to processor 304and configured to provide processor 304 with instructions. GPS (e.g.,global positioning system) 308 comprises a GPS for determining a usersystem position. In some embodiments, GPS position information istransmitted by interface 302 to a lift management system.

FIG. 4 is a diagram illustrating an embodiment of a user device displayfor a default display for indicating a pickup address to a rider system.In some embodiments, the diagram of FIG. 4 illustrates the display ofrider system 102 of FIG. 1 . In the example shown, rider system 400comprises display 402. Display 402 comprises a default display for arider system. Display 402 comprises map 404, displaying the local areaaround the rider system. Map 404 comprises local roads and geographicalfeatures, car icons indicating active driver systems (e.g., car icon406) and a pin icon indicating the rider system position (e.g., pin icon408). In some embodiments, the set of car icons indicating active driversystems comprises a set of potential drivers. Display 402 additionallycomprises pickup address entry field 410 and set pickup button 412.Pickup address entry field 410 comprises a field for a rider to enter anaddress to be picked up at. In some embodiments, a rider types a pickupaddress into pickup address entry field 410. In some embodiments, pickupaddress entry field 410 defaults to a default pickup address. In someembodiments, the default pickup address is the rider current address. Insome embodiments, the default pickup address comprises an addressderived from the rider current address (e.g., an address cluster leadlocation). In some embodiments, the default pickup address comprises acommonly used pickup address. In some embodiments, the rider can accessa list of commonly used pickup addresses (e.g., by tapping on pickupaddress entry field 410, by swiping up on map 404, by tapping on acommonly used addresses button, or by performing any other appropriateuser interface action). Set pickup button 412 initiates request of aride using the currently entered or selected pickup address.

FIG. 5 is a diagram illustrating an embodiment of a user device displayfor indicating a dropoff address to a rider system. In some embodiments,the diagram of FIG. 5 illustrates the display of rider system 102 ofFIG. 1 . In the example shown, rider system 500 comprises display 502.Display 502 comprises a display for a rider system after initiation of arequest of a ride with a pickup address (e.g., using set pickup button412 of FIG. 4 ). Display 502 comprises map 504, displaying the localarea around the rider system. Display 502 additionally comprises dropoffaddress entry field 506 and set dropoff button 508. Dropoff addressentry field 506 comprises a field for a rider to enter an address to bedropped off at. In some embodiments, a rider types a dropoff addressinto dropoff address entry field 506. In some embodiments, dropoffaddress entry field 506 defaults to a default dropoff address. In someembodiments, the default pickup address is the rider home address. Insome embodiments, the default dropoff address comprises a commonly useddropoff address. In some embodiments, the rider can access a list ofcommonly used dropoff addresses (e.g., by tapping on dropoff addressentry field 506, by swiping up on map 504, by tapping on a commonly usedaddresses button, or by performing any other appropriate user interfaceaction). Set dropoff button 508 continues request of a ride using thecurrently entered or selected dropoff address.

In some embodiments, a request for a ride is made without indicating adropoff address to the rider system, and the dropoff address isindicated by the rider directly to the driver after pickup. In variousembodiments, the rider sets a user setting (e.g., on a user settingsdisplay) indicating that he does not want to indicate a dropoffaddresses, the rider is queried after indicating a pickup addresswhether he wants to indicate a dropoff address, the rider enters nodropoff address into dropoff address entry field 506, it is determinedwhether or not a dropoff address is indicated (e.g., entered, notentered, not preferred, preferred, selected, not selected, etc.), or therider indicates whether or not to indicate a dropoff address in anyother appropriate way.

FIG. 6 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider system to request a ride. In some embodiments,the diagram of FIG. 6 illustrates the display of rider system 102 ofFIG. 1 . In the example shown, rider system 600 comprises display 602.Display 602 comprises a display for a rider system after indication of adropoff address for a ride (e.g., using set dropoff button 508 of FIG. 5). In some embodiments, display 602 comprises a display for a ridersystem after indication of a pickup address for a ride (e.g., using setpickup button 412 of FIG. 2 ) and indication not to indicate a dropoffaddress. Display 602 comprises map 604, displaying the local area aroundthe rider system and the path of the ride to be requested. Display 602additionally comprises pickup address display 606, dropoff addressdisplay 608, and request ride button 610. The rider using rider system600 reviews the path of the ride shown on map 604 and the displayedpickup and dropoff addresses. In some embodiments, the rider can returnto the pickup address entry screen, (e.g., shown in FIG. 4 ) byindicating to pickup address display 606, and the rider can return tothe dropoff address entry screen, (e.g., shown in FIG. 5 ) by indicatingto dropoff address display 608. If the user decides the addresses arecorrect and wants to request the ride, he makes an indication to requestride by activating button 610.

FIG. 7 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that drivers are being contacted. In someembodiments, the diagram of FIG. 7 illustrates the display of ridersystem 102 of FIG. 1 . In the example shown, rider system 700 comprisesdisplay 702. Display 702 comprises a display for a rider system afterindicating to request a ride (e.g., using request ride button 610 ofFIG. 6 ). Display 702 comprises map 704, displaying the local areaaround the rider system and the path of the requested ride. Display 702additionally comprises contacting drivers box 706, indicating to therider the path of the requested ride and that drivers are beingcontacted. In various embodiments, lift management system receivesinformation from rider system 700 indicating a request for a ride (e.g.,pick up address, dropoff address, etc.), determines a driver to requestwhether the driver will pick up the rider, receives acceptance of therequest for picking up the rider, providing driver and rider withacceptance information, receiving ride start and stop information (e.g.,start time, stop time, rating, etc.), donation information (e.g., amountdonated, summary of donation information, etc.), or any otherappropriate system function.

FIG. 8 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that a driver has accepted a ride request. Insome embodiments, the diagram of FIG. 8 illustrates the display of ridersystem 102 of FIG. 1 . In the example shown, rider system 800 comprisesdisplay 802. Display 802 comprises a display for a rider systemindicating that a driver has accepted the ride. Display 802 comprisesmap 804, displaying the local area around the rider system and the pathof the ride. Display 802 additionally comprises driver information,including the driver name, driver rating, driver image 806, and drivercar image 808. Driver image 806 and driver car image 808 are shown inorder that the rider will be better able to identify the driver uponarrival. Display 802 additionally comprises call driver button 810. Insome embodiments, when the rider indicates to call by activating driverbutton 810, an audio connection is made between the rider system and thedriver system, enabling the rider and the driver to talk. In someembodiments, call driver button 810 is anonymized, such that none of thedriver's information is revealed to the rider (e.g., the driver's phonenumber), and that after the ride is complete, the rider will no longerbe able to contact the driver directly. In some embodiments, none of therider's information is revealed to the driver (e.g., the rider's phonenumber), and that after the ride is complete, the driver will no longerbe able to contact the rider directly.

After the driver accepts the ride request, the driver drives to thepickup location and meets the rider. Upon arrival at the pickuplocation, a notification is sent to the rider that the driver hasarrived. The rider then boards the driver's car. When the ride starts,the rider receives a ride start notification. In some embodiments, theride start notification comprises an audio notification. The rider isthen taken to the desired destination. In some embodiments, while theride is underway, the rider is provided with a music playlist for theride. In some embodiments, while the ride is underway, the driver isprovided with a music playlist for the ride enabling the playlist to beplayed over the vehicle sound system. In some embodiments, while theride is underway, the driver and/or the rider are provided with a musicplaylist for the ride. When the destination is reached, the driverindicates that the ride is complete. In various embodiments, the riderand/or the driver are provided with mutually compatible interestinformation—for example, similar likes, similar work experience, similarother material for interesting conversation topics during the ride, orany other appropriate information. In some embodiments, the interestinformation is determined by comparing social media web page information(e.g., facebook pages).

FIG. 9 is a diagram illustrating an embodiment of a user device displayfor indicating to a rider that the ride is complete. In someembodiments, the diagram of FIG. 9 illustrates the display of ridersystem 102 of FIG. 1 . In the example shown, rider system 900 comprisesdisplay 902. Display 902 comprises a display for a rider systemindicating that the ride is complete and the rider should set a driverdonation and a driver rating. Display 902 comprises donation amountdisplay 904 and modify donation button 906. In some embodiments,donation amount display initially displays a default donation. In someembodiments, the default donation is determined based on the rideduration, ride distance, and ride region. For example, a suggesteddonation is $3+$1.75 per mile+$0.40 per minute with a minimum of $6. Inanother example, a suggested donation is $2+$2.15 per mile+$0.30 perminute with a minimum of $5. In various embodiments, modify donationbutton 906 allows a rider to modify the donation to any desired amount,a selection of amounts, any amount equal to or above a minimum amount,any amount equal to or lower than a maximum amount, or any otherappropriate amount. Driver rating interface 908 comprises a driverrating interface for allowing the rider to rate the driver. When a userhas satisfactorily chosen a driver donation and rating, he makes anindication by activating submit button 910 to submit the donation andrating information.

FIG. 10 is a diagram illustrating an embodiment of a user device displayfor menu options. In some embodiments, the diagram of FIG. 10illustrates the display of rider system 102 of FIG. 1 . In someembodiments, the diagram of FIG. 10 illustrates the display of driversystem 104 of FIG. 1 . In the example shown, user system 1000 comprisesdisplay 1002. Display 1002 comprises a display for displaying menuoptions. In the example shown, menu options comprise home button 1004,settings button 1006, help button 1008, and driver mode on button 1010and driver mode off button 1012. Home button 1004 brings a user to ahome screen. Settings button 1006 brings a user to a settings screen(e.g., a screen that enables a user to set a phone number, an emailaddress, a credit card information, and a coupon information). Helpbutton 1008 brings a user to a help screen. Driver mode on button 1010turns on driver mode, and driver mode off button 1012 turns off drivermode. In some embodiments, turning off driver mode comprises turning onpassenger mode. In various embodiments, driver mode on or off isselected using a pair of buttons, using a sliding switch, using a menu,using radio buttons, or using any other appropriate user interfacedevice. In some embodiments, a user must get prior approval before beingallowed to activate driver mode. In some embodiments, a user is not ableto see the driver mode switch in the event that the user is not approvedfor being a driver.

FIG. 11 is a diagram illustrating an embodiment of a user device displayfor a default display for a driver system. In some embodiments, thediagram of FIG. 11 illustrates the display of driver system 104 of FIG.1 . In the example shown, driver system 1100 comprises display 1102.Display 1102 comprises a default display for a driver system. Display1102 comprises map 1104, displaying the local area around the driversystem. Map 1104 comprises local roads and geographical features, caricons indicating other active driver systems and a pin icon indicatingthe driver system position. Display 1102 additionally comprises waitingfor passenger requests display 1106, indicating the driver system iswaiting for passenger requests. In various embodiments, display 1102indicates a time since last ride, a probably time to next ride, or anyother appropriate information.

FIG. 12 is a diagram illustrating an embodiment of a user device displayfor receiving a ride request for a driver system. In some embodiments, aride request comprises a rider notification. In some embodiments, thediagram of FIG. 12 illustrates the display of driver system 104 of FIG.1 . In the example shown, driver system 1200 comprises display 1202.Display 1202 comprises rider information, including a rider name, arider rating, a rider location and estimated travel time to pick up therider, and rider photo 1204. Display 1202 comprises map 1206, displayingthe local area around the driver system and the path to pick up therider. Display 1202 additionally comprises accept button 1208. In someembodiments, the ride request comprises a time limit for the driver toaccept the ride request. Accept button 1208 displays the remaining timethe driver has to accept the ride request. If the driver makes anindication by activating accept button 1208, the driver system registersthat the request has been accepted, and the driver and the rider areconnected. The driver then begins to drive to pick up the passenger.

In some embodiments, in the event that the driver does not accept theride request, the ride request is sent to the next selected driver—forexample, the lift management system determines a next driver andprovides a driver request to the driver. In some embodiments, the nextselected driver comprises one of a set of potential drivers. In someembodiments, the driver is informed of a destination (e.g., bydisplaying the destination on the map or in text).

FIG. 13 is a diagram illustrating an embodiment of a user device displayfor a driver system while driving to pick up a passenger. In someembodiments, the diagram of FIG. 13 illustrates the display of driversystem 104 of FIG. 1 . In the example shown, driver system 1300comprises display 1302. Display 1302 comprises rider information, callbutton 1304, and navigate button 1306. In some embodiments, when thedriver activates call button 1304 (e.g., taps), an audio connection ismade between the driver system and the rider system, enabling the driverand the rider to talk. In some embodiments, call driver button 1304 isanonymized, such that none of the rider's information is revealed to thedriver, and that after the ride is complete, the driver will no longerbe able to contact the rider directly. When the driver activatesnavigate button 1306, a set of turn-by-turn directions is shown ondisplay 1302, taking the driver to the rider. Display 1302 additionallycomprises map 1308, displaying the local area around the driver systemand the driver's progress along the path to pick up the rider. Display1302 additionally comprises start ride button 1310. After the passengerhas boarded the car, the driver indicates to start ride button 1310 tostart the ride duration meter. In various embodiments, start ride button1310 comprises a button, a slider, a switch, or any other appropriateuser interface device.

In some embodiments, after the driver activates start ride button 1310to start the ride duration meter, the driver then drives to the riderdestination. When the driver has reached the rider destination, thedriver indicates to an end ride button that the ride is complete. Invarious embodiments, the end ride button comprises a button, a slider, aswitch, or any other appropriate user interface device.

FIG. 14 is a diagram illustrating an embodiment of a user device displayfor rating a passenger for a driver system. In some embodiments, thediagram of FIG. 14 illustrates the display of driver system 104 of FIG.1 . In the example shown, driver system 1400 comprises display 1402.Display 1402 comprises rider information, rider rating interface 1404,and submit button 1406. Rider rating interface 1404 comprises a riderrating interface for allowing the driver to rate the rider. When adriver has satisfactorily chosen a rider rating, he makes an indicationto submit button 1406 to submit the rating information.

FIG. 15 is a flow diagram illustrating an embodiment of a process forgetting a ride. In some embodiments, the process of FIG. 15 is used by arider using a rider system (e.g., rider system 102 of FIG. 1 ) to get aride using a lift management system (e.g., lift management system 106 ofFIG. 1 ). In 1500, an indication is received of the applicationstarting. For example, the rider starts the ride app and the ride appindicates to the lift management server that it is operating.Information for display is provided to show potential drivers to arider. In 1502, an indication is received that a ride is requested. Forexample, the rider requests a ride by indicating in the app and the appprovides an indication which is received by the lift management server.In some embodiments, the ride request incudes a pickup location. In someembodiments, a ride request includes a dropoff location (e.g., that istyped in as part of the request, as selected from a list, as selected ona map, as selected from a top destination lists, etc.). In someembodiments, the top destination list is for an individual. In 1504, aconnect notification is provided. For example, a driver is selected fora requested ride from the rider, the requested ride is provided to thedriver, the driver is asked with a time limit whether the requested rideis accepted, and the driver accepts. The driver connection is indicatedto the rider. The connect notification indicates that a driver hasaccepted the ride request. In various embodiments, the connectionnotification includes one or more of the following: an image of thedriver or associated with the driver (e.g., an icon), an image of thedriver's car or associated with the driver's car (e.g., an icon), aninterface for contacting the driver (e.g., an anonymized contactinterface for contacting or calling the driver where the rider does notknow the number of the driver and the driver does not know if called thenumber of the rider), a start location (e.g., a current location of therider, a lead location—for example, a location associated with thecurrent location but preferred such as a front door of a building basedon the a current location inside the building or a corner near by thehouse instead of in front of the house, etc., a destination, or anyother appropriate information. In 1506, a notification is received ofthe ride starting. For example, the rider meets the driver (e.g., afterthe driver drives to the rider). The rider boards the vehicle. The ridersystem provides a notification of the ride starting. In someembodiments, the rider system does not provide an indication of a ridestart to the lift system manager. In 1508, a notification is received ofthe ride completing. For example, the rider rides the vehicle to thedestination. The rider system provides notification of the ride completeto the lift management system. In some embodiments, the rider systemdoes not provide an indication of the ride completion to the liftmanagement system. In 1510, donation and rating information is received.For example, the rider exits the vehicle. The rider provides a donationand/or a rating for the ride and this information is provided to thelift management system. The donation is debited from a pre-provided andpre-authorized credit card to the account of the driver. The aggregatedtotal donation for the driver is stored so that it can be provided tothe driver at the end of the current shift session or in a summaryreport.

FIG. 16 is a flow diagram illustrating an embodiment of a process forgiving a ride. In some embodiments, the process of FIG. 16 is used by adriver using a driver system (e.g., driver system 104 of FIG. 1 ) togive a ride using a lift management system (e.g., lift management system106 of FIG. 1 . In 1600, an indication is received of the applicationstarting. For example, the driver starts the ride app. In 1602, anindication is received of being in a driver mode. For example, thedriver indicates driver mode to the ride app. The app indicates to thelift management system that the app is in driver mode. A driver waitsfor a rider, as long as is necessary. In 1604, it is determined whethera driver is selected. In the event that a driver is not selected,control passes to 1604. In the event that a driver is selected, controlpasses to 1606. In 1606, a rider request is provided. For example, thedriver is provided with a rider request. In 1608, an indication isreceived of the rider request acceptance. For example, the driverindicates acceptance of the rider request to the lift management system.In the event that the driver accepts (e.g., within a time window, thedriver accepts), the driver is provided with a connect notificationincluding rider information (e.g., a picture associated with the rider,an interface for anonymized communication, a music playlist, topics forconversation, mutual interests, mutual acquaintances, similarities injob histories, similarities in living locations, similarities in tastes,etc.), a pickup location if not already provided, a destination, ifappropriate, or any other appropriate information. In 1610, anindication is received of a ride start. For example, the driver drivesto the rider location. The rider then boards the driver vehicle. Thedriver indicates that the ride has started (e.g., a time of starting aride and a location of starting a ride), and this is received by thelift management system. In 1612, an indication is received of a ridestop. For example, the driver drives to the rider destination. In someembodiments, the rider destination was entered into the ride request andis received by the ride app. In some embodiments, a destination isselected from a top destination list (e.g., by selecting on a map of topdestinations, selecting from a text list, in a history table, etc.). Insome embodiments, the rider tells the driver the destination directly.When the destination is reached, the driver indicates the ride iscomplete and this is indicated to the lift management system (e.g., thestop time, the stop location, etc.). The rider then exits the drivervehicle. In 1614, a rider rating is received. For example, the driverthen rates the rider and the rating is transmitted to and received bythe lift management system. In 1616, it is determined whether thedriving shift is complete. If it is determined that the driving shift isnot complete, control passes to 1604. If it is determined that thedriving shift is complete, control passes to 1618. In 1618, a donationsummary is received. For example, the driver receives a donation summaryof all the donations received for the driving shift.

FIG. 17 is a flow diagram illustrating an embodiment of a process forindicating a lead location. In some embodiments, a lead locationcomprises a location chosen to represent a cluster of nearby locations.For example, if a rider was picked up four times from slightly differentlocations near the entry to his office, the four pickups would naturallyform a cluster, and the office address would more appropriatelyrepresent the cluster than the back alley address or the next dooraddress. In 1700, pickup and dropoff events are recorded. Each eventcomprises a location, a time, a means of entering the location into theapp, and any other appropriate information. In 1702, each event isassociated with a location cluster. In some embodiments, events areassociated with a location cluster using the k-means algorithm. In someembodiments, events are associated with a location cluster byassociating them with a set of other events with nearby locations. In1704, each event is associated with a weight. In some embodiments, theweight is determined by determining the method that was used to enterthe location in to the app (e.g., the selector). For example, a typedaddress (e.g., weighted 1000) is weighted more than moving a pinmanually on a map (e.g., weighted 25), which in turn is weighted morethan a global positioning location (e.g., weighted 3). In 1706, eventweights for each distinct location in the location cluster are summed.For instance, if there are four events in the location cluster with theidentical associated locations, their weights are summed and associatedwith the location. In 1708, the location in the cluster with the highesttotal weight is determined. In 1710, the location in the cluster withthe highest total weight is indicated as the cluster lead location. If alocation is entered into the app later that is grouped with the samelocation cluster, the location will then be represented by the clusterlead location rather than the entered location.

In some embodiments, the addresses are normalized so that a locationthat a location that has been used multiple times appears only once inthe list of addresses for a cluster. Each time someone selects theirpick-up or drop-off locations, the method with which they selected thatlocation is stored. We sum up these location selectors per address percluster. So a cluster would look like the following:

a. cluster 1

-   -   i. Location A        -   1. selector: defaultList        -   2. selector: defaultList        -   3. selector: typedInput    -   ii. Location B        -   1. selector: unknown

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. A computer-implemented method comprising:generating, via one or more servers, a plurality of pickup locationclusters from historical events comprising historical pickup locationscorresponding to requestor computing devices by utilizing a clusteringalgorithm to cluster the historical events according to relationshipsbetween the historical pickup locations and stored locations associatedwith user accounts; generating, via the one or more servers, a pluralityof lead locations for the plurality of pickup location clusters bydetermining event weights for the historical events and combining thehistorical events corresponding to the plurality of pickup locationclusters according to the event weights; receiving, via the one or moreservers from a requestor computing device, a ride request indicating arequested pickup location; determining that the requested pickuplocation corresponds to a pickup location cluster from the plurality ofpickup location clusters; based on determining that the requested pickuplocation corresponds to the pickup location cluster, selecting, via theone or more servers, a lead location for the pickup location clusterfrom the plurality of lead locations as a pickup location for the riderequest; and providing, for display on the requestor computing device, apickup location pin indicating the pickup location for the ride request.2. The computer-implemented method of claim 1, wherein generating theplurality of pickup location clusters comprises clustering thehistorical pickup locations based on distances between the historicalpickup locations.
 3. The computer-implemented method of claim 1, whereinreceiving the ride request indicating the requested pickup locationcomprises one or more of: receiving an indication of user input placinga pin on a digital map displayed on the requestor computing device;receiving an indication of user input entering a typed address in anaddress entry field displayed on the requestor computing device;receiving in indication of user input selecting an address from a listof commonly used pickup addresses presented via the requestor computingdevice; or determining a global positioning location of the requestorcomputing device for the ride request.
 4. The computer-implementedmethod of claim 1, wherein generating the plurality of lead locationscomprises: determining, for a certain pickup location cluster from amongthe plurality of pickup location clusters, a first location weight for afirst historical pickup location and a second location weight for asecond historical pickup location within the certain pickup locationcluster; and selecting the second historical pickup location as a leadlocation for the certain pickup location cluster based on determiningthat the second location weight is greater than the first locationweight.
 5. The computer-implemented method of claim 4, furthercomprising determining the first location weight and the second locationweight by combining individual weights associated with historical eventsthat occurred at the first historical pickup location and the secondhistorical pickup location, respectively.
 6. The computer-implementedmethod of claim 1, further comprising: storing, within a computerdatabase, an account location for a user account associated with therequestor computing device; generating an additional pickup locationcluster from a plurality of historical pickup locations of previous riderequests received from the requestor computing device of the useraccount, wherein the plurality of historical pickup locations occurwithin a distance of the account location; and selecting the accountlocation as a lead location for the additional pickup location cluster.7. The computer-implemented method of claim 1, wherein determining thatthe requested pickup location corresponds to the pickup location clustercomprises determining that the requested pickup location is within adistance of the lead location of the pickup location cluster.
 8. Asystem comprising: at least one processor; and at least onenon-transitory computer readable storage medium storing instructionsthat, when executed by the at least one processor, cause the system to:generate, via one or more servers, a plurality of pickup locationclusters from historical events comprising historical pickup locationscorresponding to requestor computing devices by utilizing a clusteringalgorithm to cluster the historical events according to relationshipsbetween the historical pickup locations and stored locations associatedwith user accounts; generate, via the one or more servers, a pluralityof lead locations for the plurality of pickup location clusters bydetermining event weights for the historical events and combining thehistorical events corresponding to the plurality of pickup locationclusters according to the event weights; receive, via the one or moreservers from a requestor computing device, a ride request indicating arequested pickup location; determine that the requested pickup locationcorresponds to a pickup location cluster from the plurality of pickuplocation clusters; based on determining that the requested pickuplocation corresponds to the pickup location cluster, select, via the oneor more servers, a lead location for the pickup location cluster fromthe plurality of lead locations as a pickup location for the riderequest; and provide, for display on the requestor computing device, apickup location pin indicating the pickup location for the ride request.9. The system of claim 8, further comprising instructions that, whenexecuted by the at least one processor, cause the system to generate theplurality of pickup location clusters comprises clustering thehistorical pickup locations based on distances between the historicalpickup locations.
 10. The system of claim 8: further comprisinginstructions that, when executed by the at least one processor, causethe system to receive the ride request indicating the requested pickuplocation by one or more of: receiving an indication of user inputplacing a pin on a digital map displayed on the requestor computingdevice; receiving an indication of user input entering a typed addressin an address entry field displayed on the requestor computing device;receiving in indication of user input selecting an address from a listof commonly used pickup addresses presented via the requestor computingdevice; or determining a global positioning location of the requestorcomputing device for the ride request.
 11. The system of claim 8,further comprising instructions that, when executed by the at least oneprocessor, cause the system to generate the plurality of lead locationscomprises: determining, for a certain pickup location cluster from amongthe plurality of pickup location clusters, a first location weight for afirst historical pickup location and a second location weight for asecond historical pickup location within the certain pickup locationcluster; and selecting the second historical pickup location as a leadlocation for the certain pickup location cluster based on determiningthat the second location weight is greater than the first locationweight.
 12. The system of claim 11, further comprising instructionsthat, when executed by the at least one processor, cause the system todetermine the first location weight and the second location weight bycombining individual weights associated with historical events thatoccurred at the first historical pickup location and the secondhistorical pickup location, respectively.
 13. The system of claim 8,further comprising instructions that, when executed by the at least oneprocessor, cause the system to: storing, within a computer database, anaccount location for a user account associated with the requestorcomputing device; generating an additional pickup location cluster froma plurality of historical pickup locations of previous ride requestsreceived from the requestor computing device of the user account,wherein the plurality of historical pickup locations occur within adistance of the account location; and selecting the account location asa lead location for the additional pickup location cluster.
 14. Thesystem of claim 8, further comprising instructions that, when executedby the at least one processor, cause the system to determine that therequested pickup location corresponds to the pickup location cluster bydetermining that the requested pickup location is within a distance ofthe lead location of the pickup location cluster.
 15. A non-transitorycomputer readable medium storing instructions thereon that, whenexecuted by at least one processor, cause a computer system to:generate, via one or more servers, a plurality of pickup locationclusters from historical events comprising historical pickup locationscorresponding to requestor computing devices by utilizing a clusteringalgorithm to cluster the historical events according to relationshipsbetween the historical pickup locations and stored locations associatedwith user accounts; generate, via the one or more servers, a pluralityof lead locations for the plurality of pickup location clusters bydetermining event weights for the historical events and combining thehistorical events corresponding to the plurality of pickup locationclusters according to the event weights; receive, via the one or moreservers from a requestor computing device, a ride request indicating arequested pickup location; determine that the requested pickup locationcorresponds to a pickup location cluster from the plurality of pickuplocation clusters; based on determining that the requested pickuplocation corresponds to the pickup location cluster, select, via the oneor more servers, a lead location for the pickup location cluster fromthe plurality of lead locations as a pickup location for the riderequest; and provide, for display on the requestor computing device, apickup location pin indicating the pickup location for the ride request.16. The non-transitory computer readable medium of claim 15, furthercomprising instructions that, when executed by the at least oneprocessor, cause the computer system to generate the plurality of pickuplocation clusters comprises clustering the historical pickup locationsbased on distances between the historical pickup locations.
 17. Thenon-transitory computer readable medium of claim 15, further comprisinginstructions that, when executed by the at least one processor, causethe computer system to receive the ride request indicating the requestedpickup location by one or more of: receiving an indication of user inputplacing a pin on a digital map displayed on the requestor computingdevice; receiving an indication of user input entering a typed addressin an address entry field displayed on the requestor computing device;receiving in indication of user input selecting an address from a listof commonly used pickup addresses presented via the requestor computingdevice; or determining a global positioning location of the requestorcomputing device for the ride request.
 18. The non-transitory computerreadable medium of claim 15, further comprising instructions that, whenexecuted by the at least one processor, cause the computer system togenerate the plurality of lead locations comprises: determining, for acertain pickup location cluster from among the plurality of pickuplocation clusters, a first location weight for a first historical pickuplocation and a second location weight for a second historical pickuplocation within the certain pickup location cluster; and selecting thesecond historical pickup location as a lead location for the certainpickup location cluster based on determining that the second locationweight is greater than the first location weight.
 19. The non-transitorycomputer readable medium of claim 15, further comprising instructionsthat, when executed by the at least one processor, cause the computersystem to generate the plurality of lead locations comprises:determining, for a certain pickup location cluster from among theplurality of pickup location clusters, a first location weight for afirst historical pickup location and a second location weight for asecond historical pickup location within the certain pickup locationcluster; and selecting the second historical pickup location as a leadlocation for the certain pickup location cluster based on determiningthat the second location weight is greater than the first locationweight.
 20. The non-transitory computer readable medium of claim 15,further comprising instructions that, when executed by the at least oneprocessor, cause the computer system to: storing, within a computerdatabase, an account location for a user account associated with therequestor computing device; generating an additional pickup locationcluster from a plurality of historical pickup locations of previous riderequests received from the requestor computing device of the useraccount, wherein the plurality of historical pickup locations occurwithin a distance of the account location; and selecting the accountlocation as a lead location for the additional pickup location cluster.